Systems and devices for encrypting, converting and interacting with medical images using a mobile device

ABSTRACT

A network device and a peripheral device for attachment with a medical imaging device provides for the encryption and conversion of a medical image into a secure and standardized image file format as well as the communication of the encrypted and/or converted image to a secure server on a remote network. The devices may monitor all medical image files generated on the medical imaging device and encrypt and convert selected medical image files for transmission to a remotely connected device on another network, such as a server or a mobile device. An encryption and conversion unit may be incorporated within the hardware and software of a medical imaging device or another network device in order to provide the capability for encrypting a medical image for transmission to a remote network and for converting the medical image to a format that is compatible with a destination device or network. Systems and methods for real-time remote interaction with medical images is provided, which allows for medical images from a medical imaging device to be shared across a common user interface to users in multiple different locations. The users may then collaborate to discuss, annotate and review the image in real-time, improving the collaboration between users and reducing the amount of time needed to make a diagnosis.

BACKGROUND

1. Technical Field

The embodiments described herein are related to delivery of medicalimage records, and more particularly to the automatic encryption andconversion of medical image files for delivery to mobile devices and/orremote communication systems.

2. Related Art

Medical diagnostic devices and medical imaging systems have becomeincreasingly complex in recent years. In response to the increasingchallenges in digital imaging technology, the American College ofRadiology (ACR) and the National Electrical Manufacturers Association(NEMA) developed the Digital Imaging and Communications in Medicine(DICOM) standard. DICOM is a standard for handling, storing, printing,and transmitting information in medical imaging. It includes a fileformat definition and a network communication protocol. The networkcommunication protocol is an application protocol that uses TCP/IP tocommunicate between systems. One of the goals of the standard is to makeuniform the transferring of medical images and information betweenviewing and scanning sources to allow users of different imagingsoftware and/or hardware to share information. DICOM files can beexchanged between two entities that are capable of receiving image andpatient data in DICOM format. DICOM enables the integration of scanners,servers, workstations, printers, and network hardware from multiplemanufacturers into a Picture Archiving and Communication System (PACS)for storing and downloading of digital images. The different devicescome with DICOM conformance statements that clearly state the DICOMclasses they support. DICOM has been widely adopted by hospitals, and isgaining popularity in smaller dentists' and doctors' offices.

DICOM files commonly contain images; therefore, they are often referredto as DICOM images. But it will be understood that a DICOM file does notnecessarily need to include an image. Rather, such a file can includemeasurements or report data. Thus, DICOM files may contain media data,such as, video and audio data, or no media data at all. In that case,DICOM files may contain only metadata identifying the originatingmodality, the operator, or the patient being examined. Modality hererefers to any image generating equipment in medical imaging, such as,Ultrasound (US), Magnetic Resonance Imaging (MRI), Computed Tomography(CT), Positron Emission Tomography (PET), radiographs, and the like.

The type of data and amount of data available in any one DICOM imagefile varies. A DICOM file is generally structured using data identifyingPatient, Study, Series and Instance in that hierarchical order. APatient can be involved in a number of Studies (cases), which in turnmay contain a number of Series (examination or visits), which in turnmay contain a number of Instances (files usually containing images). Itmeans that a DICOM file can be unambiguously identified and fitted intothat hierarchy. All DICOM files contain an identifier for the generatingmodality. In other words, the identifier will reflect the equipment orlocation in which the file was originated. The files also containtimestamps pertaining to both the file itself (Instance) and the Series.Using the timestamps and the originating identifier, an image can beunambiguously identified using that data without involving anyidentifiable patient information to safeguard patient privacy issues. Inaddition, DICOM file format differs from other data formats in that itgroups information into data sets. For example, a file of a chest X-Rayimage actually contains the patient ID within the file, so that theimage can never be separated from this information by mistake.

Most PACSs handle images from various medical imaging instruments,including US, MRI, PET, CT, and the like. Electronic images and reportsare transmitted digitally via PACS; this eliminates the need to manuallyfile, retrieve or transport film jackets. A PACS consists of four majorcomponents: the imaging modalities, such as, CT and MRI; a securednetwork for the transmission of patient information; workstations forinterpreting and reviewing images; and long and short term archives forthe storage and retrieval of images and reports. Combined with availableand emerging Web technology, PACS has the ability to deliver timely andefficient access to images, interpretations and related data. PACSbreaks down the physical and time barriers associated with traditionalfilm-based image retrieval, distribution and display.

Medical imaging devices typically output digital image data. Theoverwhelming majority, if not all, of such devices use the DICOMstandard for both image file format and network transfers. These imagesare generally not readable by consumer image viewers or mobile devices.Therefore, patients who wish to share their medical images struggle withconversion and delivery of these images. A good example is to shareimages from an Ultrasound examination during a pregnancy. The futureparents usually would like to keep, share and display the images oftheir future child. They might also conceivably want to send theseimages to their friends' and relatives' cellular phones or emailaccounts. They might even want to post them on a social network, or theymight just want to keep them in their personal digital “photo album”.All of these events would require them to either scan a printedhard-copy of the image, or to find, purchase, install and learn to useDICOM viewer software package with export capabilities. These softwarepackages are usually not readily available or they are not economicalfor limited use.

It should also be noted that this issue is not necessarily limited toDICOM files. In general, there is no real method for a patient to viewimages related to their condition, treatment, status, etc. Moreover,there are few, if any effective means by which a doctor or clinician canquickly and remotely retrieve images for diagnostic or other purposes.

In fact, many smaller medical practices, such as, small clinics,doctors' offices, and dentists' offices also suffer from an inability toconvert, deliver, and receive medical images economically and timely.These facilities usually do not have the technical support-staff orfinances to run a full PACS for image archiving and delivery to remoteexpert doctors for second opinions and consultations. They often resortto using films, or writable CDs which are sent by mail or messenger.This is both slow, environmentally unfriendly and, in the case of usingunregistered postal delivery, insecure. The cost of running a PACS isnot just paying the licensing fees. Major investments in advancedinfrastructure including the surrounding software, hardware, andfacility, as well as the cost for educating staff, and the hours spenton administration will add to the cost of running a PACS. These majorinvestments are expensive, therefore, usually out-of-reach for mostsmall businesses.

Additionally, many medical practices may not have a local network wheremedical imaging equipment communicates, or the local network may not besecure or properly configured to receive and communicate medical images.The medical imaging devices themselves often lack the capability toencrypt or convert the captured images. The local network, if it doesexist, may be incapable of incorporating network devices such as a PACSfor the management of digital images.

SUMMARY

A peripheral device for attachment with a medical imaging deviceprovides for the encryption and conversion of a medical image into asecure and standardized image file format as well as the communicationof the encrypted and/or converted image to a secure server on a remotenetwork.

According to one aspect, a peripheral encryption and conversion devicecomprises a communication interface which receives a medical image file,the medical image file comprising medical data and meta data, themedical data having a medical data format; a conversion unit whichconverts the medical data format associated with the medical data basedon standardized format specifications that correlate with an outputdestination type to create a converted medical image file; an encryptionunit which encrypts the converted medical image file to create anencrypted medical image file; and a transmission unit which transmitsthe encrypted medical image file.

According to one aspect, a system for automated conversion and deliveryof medical images, comprising: a communication interface; a data storagesystem configured to store a plurality of medical images, meta dataassociated with the plurality of medical images, converted medicalimages, a plurality of standardized format specifications for aplurality of destination devices and services, and a plurality ofmessage templates; a server coupled with the data storage system and thecommunication interface, the server configured to: receive a medicalimage file via the communications interface, the medical image filecomprising medical data and meta data, the medical data having a medicaldata format that complies with the digital imaging and communication inmedicine standard, determine whether the medical data includes a medicalimage data, determine an output destination type, wherein the outputdestination type is an output device, service, or both, based on themeta data, correlate the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates, convert the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type, assembleat least one output message that includes the converted medical databased on the message templates that correlate with the outputdestination type, and transmit the output message to at least onedestination via the communication interface.

According to another aspect, a method for automated conversion anddelivery of medical images, comprising: storing a plurality of medicalimages, meta data associated with the plurality of medical images,converted medical images, a plurality of standardized formatspecifications for a plurality of destination devices and services, anda plurality of message templates; receiving a medical image file via acommunications interface, the medical image file comprising medical dataand meta data, the medical data having a medical data format;determining whether the medical data includes a medical image data;determining an output destination type, wherein the output destinationtype is an output device, service, or both, based on the meta data;correlating the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates; converting the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type;assembling at least one output message that includes the convertedmedical data based on the message templates that correlate with theoutput destination type; and transmitting the output message to at leastone destination via the communication interface.

A network device may be implemented on a local network to receivemedical images from one or more medical imaging devices and convert andencrypt the medical images into a secure and standardized image fileformat, as well as communicate the encrypted and/or converted image to asecure server on a remote network.

According to one aspect, a network encryption and conversion devicecomprises a communication interface which receives a medical image filefrom at least one medical imaging device, the medical image filecomprising medical data and meta data, the medical data having a medicaldata format; a conversion unit which converts the medical data formatassociated with the medical data based on standardized formatspecifications that correlate with an output destination type to createa converted medical image file; an encryption unit which encrypts theconverted medical image file to create an encrypted medical image file;and a transmission unit which transmits the encrypted medical image fileto a remote device on a remote network.

According to one aspect, a system for automated conversion and deliveryof medical images, comprising: a communication interface; a data storagesystem configured to store a plurality of medical images, meta dataassociated with the plurality of medical images, converted medicalimages, a plurality of standardized format specifications for aplurality of destination devices and services, and a plurality ofmessage templates; a server coupled with the data storage system and thecommunication interface, the server configured to: receive a medicalimage file via the communications interface, the medical image filecomprising medical data and meta data, the medical data having a medicaldata format that complies with the digital imaging and communication inmedicine standard, determine whether the medical data includes a medicalimage data, determine an output destination type, wherein the outputdestination type is an output device, service, or both, based on themeta data, correlate the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates, convert the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type, assembleat least one output message that includes the converted medical databased on the message templates that correlate with the outputdestination type, and transmit the output message to at least onedestination via the communication interface.

According to another aspect, a method for automated conversion anddelivery of medical images, comprising: storing a plurality of medicalimages, meta data associated with the plurality of medical images,converted medical images, a plurality of standardized formatspecifications for a plurality of destination devices and services, anda plurality of message templates; receiving a medical image file via acommunications interface, the medical image file comprising medical dataand meta data, the medical data having a medical data format;determining whether the medical data includes a medical image data;determining an output destination type, wherein the output destinationtype is an output device, service, or both, based on the meta data;correlating the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates; converting the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type;assembling at least one output message that includes the convertedmedical data based on the message templates that correlate with theoutput destination type; and transmitting the output message to at leastone destination via the communication interface.

Systems and methods for encrypting and converting medical image files ona device within a network are provided. An encryption and conversionunit may be incorporated within the hardware and software of a medicalimaging device or another network device in order to provide thecapability for encrypting a medical image for transmission to a remotenetwork and for converting the medical image to a format that iscompatible with a destination device or network. The encryption andconversion unit may also be configured to package and transmit aconverted and encrypted image to an appropriate destination, such as asecure server, on a remote network.

According to one aspect, a system for converting and encrypting amedical image comprises a medical imaging device which captures at leastone medical image file; the medical imaging device comprising: acommunication interface which receives the medical image file from themedical imaging device, the medical image file comprising medical dataand meta data, the medical data having a medical data format; aconversion unit which converts the medical data format associated withthe medical data based on standardized format specifications thatcorrelate with an output destination type to create a converted medicalimage file; an encryption unit which encrypts the converted medicalimage file to create an encrypted medical image file; and a transmissionunit which transmits the encrypted medical image file to at least onedestination via the communication interface.

According to one aspect, a system for automated conversion and deliveryof medical images, comprising: a communication interface; a data storagesystem configured to store a plurality of medical images, meta dataassociated with the plurality of medical images, converted medicalimages, a plurality of standardized format specifications for aplurality of destination devices and services, and a plurality ofmessage templates; a server coupled with the data storage system and thecommunication interface, the server configured to: receive a medicalimage file via the communications interface, the medical image filecomprising medical data and meta data, the medical data having a medicaldata format that complies with the digital imaging and communication inmedicine standard, determine whether the medical data includes a medicalimage data, determine an output destination type, wherein the outputdestination type is an output device, service, or both, based on themeta data, correlate the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates, convert the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type, assembleat least one output message that includes the converted medical databased on the message templates that correlate with the outputdestination type, and transmit the output message to at least onedestination via the communication interface.

According to another aspect, a method for automated conversion anddelivery of medical images, comprising: storing a plurality of medicalimages, meta data associated with the plurality of medical images,converted medical images, a plurality of standardized formatspecifications for a plurality of destination devices and services, anda plurality of message templates; receiving a medical image file via acommunications interface, the medical image file comprising medical dataand meta data, the medical data having a medical data format;determining whether the medical data includes a medical image data;determining an output destination type, wherein the output destinationtype is an output device, service, or both, based on the meta data;correlating the output destination type with one or more of theplurality of standardized format specifications and with one or more ofthe plurality of message templates; converting the medical data formatassociated with the medical data based on the standardized formatspecifications that correlate with the output destination type;assembling at least one output message that includes the convertedmedical data based on the message templates that correlate with theoutput destination type; and transmitting the output message to at leastone destination via the communication interface.

Systems and methods for integrating a variety of communication protocolsand file types relating to medical imaging are provided.

According to one aspect, a system for automated conversion and deliveryof medical images, comprising: a communication interface; a userinterface; a data storage system configured to store a plurality ofmedical images, meta data associated with the plurality of medicalimages, converted medical images, a plurality of standardized formatspecifications for a plurality of destination devices and services, anda plurality of message templates; a server coupled with the data storagesystem and the communication interface, the server configured to:receive a plurality of medical image files via the communicationsinterface, the medical image files comprising medical data and metadata, the medical data having a medical data format, store the medicalimage files, receive a request via the user interface to find a medicalimage file, return a notification that the requested medical image filehas been found via the user interface, receive an output destinationtype associated with the medical data file via the user interface,wherein the output destination type is an output device, service, orboth, retrieve the requested medical image file, determine whether themedical data associated with the requested medical image file includesmedical image data, correlate the output destination type with one ormore of the plurality of standardized format specifications and with oneor more of the plurality of message templates, convert the medical dataformat associated with the medical data based on the standardized formatspecifications that correlate with the output destination type, assembleat least one output message that includes the converted medical databased on the message templates that correlate with the outputdestination type, and transmit the output message to at least onedestination via the communication interface.

These and other features, aspects, and embodiments are described belowin the section entitled “Detailed Description.”

BRIEF DESCRIPTION OF THE DRAWINGS

Features, aspects, and embodiments are described in conjunction with theattached drawings, in which:

FIG. 1 is a diagram illustrating an example system for the automaticconversion and distribution of medical images to any of a plurality ofoutput modalities in accordance with one embodiment;

FIG. 2 is a high level block diagram illustrating certain components ofan example data conversion and delivery system that can be included inthe system of FIG. 1 in accordance with one embodiment;

FIG. 3 is a flow chart illustrating an example automated messagecreation process performed by the data conversion and delivery system ofFIG. 2 in accordance with one embodiment;

FIG. 4 is a flow chart illustrating example type of information and datathat can be examined in the process of FIG. 3 in accordance with oneembodiment;

FIG. 5 is a flow chart illustrating an example process for the use ofinformation embedded inside of the metadata included with incoming filesby the data conversion and delivery system of FIG. 2 in accordance withone embodiment;

FIG. 6 is a flow chart that illustrates the operation of an imageconverter module that can be included in the data conversion anddelivery system of FIG. 2;

FIG. 7 is a flow chart illustrating a typical use of a Web GUI that canbe included in the data conversion and delivery system of FIG. 2 and itsstreamlined interface for finding an image by the originating modalitywithout any identifiable patient information in accordance with oneembodiment;

FIG. 8 is a flow chart illustrating a variation of the typical use ofthe Web GUI and its streamlined interface for finding an image by usinga piece of identifiable patient data in accordance with one embodiment;

FIG. 9 is a diagram illustrating an example system for the automaticconversion and distribution of medical images to any of a plurality ofoutput modalities in accordance with another embodiment; and

FIG. 10 is an illustration of a peripheral device connected with amedical imaging device and a remote server for converting and encryptingmedical image files from the medical imaging device, according to oneembodiment of the invention.

FIG. 11 is an illustration of a network device connected with a medicalimaging device and a remote server for converting and encrypting medicalimage files from the medical imaging device, according to one embodimentof the invention; and

FIG. 12 is a flowchart diagram of the signal flow through the network.

FIG. 13 is an illustration of a system for converting and encrypting amedical image with an encryption and conversion unit, a medical imagingdevice and a remote server, according to one embodiment of theinvention;

FIGS. 14 and 15 illustrate traditional workflows for medical imagesharing in a primary care and emergency room setting;

FIG. 16 is a flow chart of one embodiment of a system for real-timeremote interactive collaboration for medical diagnoses;

FIG. 17 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 18 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 19 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 20 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 21 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 22 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 23 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 24 illustrates a user interfaces which users of the real-timeremote interaction system will view;

FIG. 25 illustrates a user interfaces which users of the real-timeremote interaction system will view; and

FIG. 26 is an illustration of a mobile device connected with a medicalimaging device and a remote server for converting and encrypting medicalimage files from the medical imaging device, according to one embodimentof the invention.

DETAILED DESCRIPTION

FIG. 1 is a diagram illustrating an example system 100 for the automaticconversion and distribution of medical images to any of a plurality ofoutput modalities. The term output modality is used to refer to varioustypes of devices, systems, and services, several examples of which areprovided below. As can be seen, system 100 can comprise a plurality ofsource medical imaging modalities 10, such as Ultrasound, MRI, CT andPET equipment, a local PACS 20 (typically source image archive-servers),or any other device capable of sending medical data such as DICOM data,commonly medical images. Modalities 10 and PACS 20 can be connected,e.g., with a Central Computer System (CCS) 30 via the Internet 60through a router 50 usually provided with encryption and firewallprotection.

Central Computer System (CCS) 30 can include a data conversion anddelivery system (DCDS) 32 for processing the medical data. The CCS cancomprise one or more servers, and include one or more a processors orCPUs, memory associated with the processor(s), a data storage module, adisplay means, and an input/output interface means. It should beappreciated that various other peripheral devices and modules can beconnected to the CCS, such as other servers, other data storage modules,or intrusion detection systems. The CCS can also be a cluster ofinteroperating servers, each taking care of a specific task within thesystem. Similarly, all the modules shown in FIG. 2, and described belowcan each be a separate server in such a cluster, so as to distribute theload and increase the capacity of the system.

DCDS 32 can be configured to convert medical images associated with themedical data into, e.g., consumer-friendly images, video, or both. DCDS32 can then in turn send these converted images to a number ofdestinations, or output modalities 40 as directed by the user/operatorof DCDS 32 or as dictated by information included in the medical data.These destinations 40 can be, for example, a web site such as a socialnetworking site including, e.g., Twitter, Facebook, and Google Health;cellular phones; PDAs; Email accounts; or any computer system capable ofaccepting data via protocols such as, e.g., SOAP and REST. DCDS 32functions in such a way that it allows source modalities (10, 20) to beprotected by the most rigorous of firewall settings 50, while stillallowing transfers to take place over the internet 60. The originalsource image data may optionally be sent to the destinations 40 withoutany processing or conversion.

For example, when a patient undergoes an ultrasound examination duringpregnancy, the ultrasound images can be sent to DCDS 32 for conversioninto a set of images that can be sent the parent's social networking webpage, their mobile device, their friends and families devices or webpages, etc. More specifically, a nice sequence of the fetus waving itsarm can be captured and stored during the ultrasound examination by theoperator. The ultrasound operator, usually a nurse or technician, sendsthe stored, e.g., DICOM file to DCDS 32. The nurse, technician or anytrusted employee at the patient's facility (user) can use a remotegraphical user interface (GUI) interfaced with DCDS 32 to bring up thedesired sequence sent by the source modality 10. The user can then enterthe cellular phone numbers, web account information, email addresses,etc., as well as any personal message that the patient indicates, andthen start the delivery process. The, e.g., DICOM file, now convertedinto a cellular phone compatible video format, e.g., 3gpp, can then besent as a multimedia message to the mobile phones, and files convertedto other appropriate formats can also be sent to the given email and webaccounts.

Alternatively, the nurse or technician at the patient's facility canenter the patient's cellular phone number in the patient informationfield on the ultrasound machine. On receiving the, e.g., DICOM datafile, DCDS 32 can be configured to then locate that number embedded inthe DICOM data file, and automatically forward the converted image orvideo file after processing to the desired locations as specified by thepatient. Examples of these processes are described in detail below.

FIG. 2 is a high level block diagram illustrating certain components ofan example DCDS 32 in accordance with one embodiment. It will beunderstood that the diagram of FIG. 2 is for purposes of explanation andillustration and is not intended to restrict the embodiments describedherein to any particular architecture or design. Nor is FIG. 2 intendedto provide a detail view of all components of an example DCDS 32. Inoperation, a request from a modality 10 can be handled by an inputstage, consisting of a Receiver 203 and Storage & Parser 204. TheReceiver 203 can be configured to authenticate the connection from thesource modality 10, and to handle the network transactions necessary tocomplete the request.

Storage & Parser 204 can be configured to parse the received data and tostore any image data 205 and all metadata 206 in storage system 214. Forexample, the image data 205 can be stored as binary data, while themetadata can be stored as structured data allowing typical structuredaccess to the data, such as, searches and associations between differentitems. Storage & Parser 204 can be configured in certain implementationsor under certain conditions to strip all sensitive patient informationfrom the incoming data file. For example, an operator of the system canuse a Graphical User Interface (GUI), such as a Web GUI 208 toselectively set the parts of metadata that are considered to besensitive. Alternatively, the system can be programmed to automaticallydetermine which fields in the meta data are sensitive. This process iscalled anonymization, and it is performed in order to protect thepatient's privacy. Anonymization is discussed in more detail below.

In certain embodiments, an event signal can be triggered indicating thatthe newly stored data has been added. When Event System module 209receives an event signal from the parser 204, it can be configured todetermine what action, if any, should be taken as a result. For example,if rules for automatic delivery have been set, and the appropriatemetadata values are found in the newly received data stored instructured database 206, then Event System module 209 can be configuredto signal the Output Module 213 to send the converted data as instructedby the automatic delivery rules. This process is also described in moredetail below.

Output Module 213 can be configured to accept calls from other parts ofDCDS 32 containing general data, information to send, and number ofdelivery destinations, including email addresses. For example, the datacan include a text message, a reference to a, e.g., DICOM image, twocellular phone numbers, and one email address. The Output Module 213 canbe configured to assemble the appropriate formatted output “packages”,or messages, and send the resulting messages using a modularplug-in-based architecture. A plug-in (not shown) for each correspondingtype of destination can be included and used by Output Module 213.

In the example provided above, when a service call is received by DCDS32, Output Module 213 can assemble one MMS message packet containing ajpeg version of an image and message text, all combined and encodedaccording to the MMS specifications. This message can then be senttwice, first to each phone number destinations requested, and secondly,to each email address destinations specified.

Output Module 213 can request a converted image from Image Converter211, identifying the original image and specifying the requested formatand dimensions. Image Converter 211 can be configured to then look foran existing image in the Converted Image Cache 212 that matches therequest. If no match is found, it can generate an image from theoriginal image data 205. The Image Converter 211 can be configured touse the metadata 206 of the original image stored in database todetermine if the requested format is appropriate. If not, it can respondwith an error. For example, requesting an mp3 audio version of a stillimage would result in an error, while requesting a jpeg still image of amulti-frame DICOM image file (effectively video) would be proper.

Image Converter 211 can be configured to respond to an event from Parser204 and perform common conversions preemptively. This will improve theresponsiveness of the system components, in particular, the OutputModule 213 and the Web GUI 208; however, the trade-off is an increase instorage required, and also a slight decrease in the overall securitylevel.

A Web GUI 208 provides, e.g., medical staff with remote access to DCDS32 via a secured web browser connection (https) 202. Such a Web GUI 208can provide an interface to perform administrative tasks such as settingup rules for Event System module 209, as well as an optimized interfacefor identifying images and sending output messages. The typicaloperations of these interfaces are described in detail below.

Web GUI 208 can operate on the structured metadata 206 to find andidentify images. It can be configured to request conversions from ImageConverter 211 to, e.g., display thumbnails and previews of images, andto provide service request forms where output messages can be specifiedand send on to Output Module 213 for delivery.

An adaptable Garbage Collector 207 can continually evaluate the state ofall data and compare that to configurations made by an administrator ofthe system. The configuration can set certain criteria that items needto meet in order to remain in the system or be deleted from the system.One basic criterion can be the age of an item. For example, if an itemhas been stored over a week ago or certain number of days ago could beautomatically deleted. Other automatic deletion criteria can be thenumber of times an item has been previously sent, system stateinformation stored, and the value of any metadata. This feature is inpart useful for keeping the resource usage down, and also to aid patientconfidentiality by removing patent data that the system is no longerneeded to maintain.

It should be noted that in some embodiments the images are to be usedfor clinical or diagnostic purposes. In such instances, it is oftenrequired that the image that is ultimately displayed on the device usedfor viewing the images maintain a certain resolution or image quality.As such, in certain embodiments, one or more of Parser 204, Event Systemmodule 209, and Image Converter 211 can be configured, either alone orin combination, to recognize that the image is being viewed in adiagnostic or clinical application. Such recognition can be based oninformation included in the meta data, information stored in ImageSystem 214, or information provided via GUI 208.

For example, the address or device identified in the meta data forreceiving the image can be recognizable as an address or deviceassociated with a clinical or diagnostic application, the image orseries identifier can also be associated with a clinical or diagnosticapplication, etc. Alternatively, an operator can indicate through GUI208 that images to be sent are intended for clinical or diagnosticpurposes.

When it is determined that the images are to be used for clinical ordiagnostic purposes, then Image Converter 211 can be configured todetermine, e.g., based on information stored in storage system 214, therequired resolution or image quality. For example, resolution, imagequality, or both for various types of images, clinical applications,etc., can be stored in storage system 214. Image converter can thendetermine the correct image resolution and quality and covert the imagein accordance therewith. In certain embodiments, DCDS 32 can beconfigured to determine whether the identified output device or addressis capable of displaying the converted image with the requisite imageresolution and quality before sending the image. If the device oraddress is not capable, then DCDS can generate an error message or othernotification indicating such. The error message can be displayed throughGUI 208, on the device, or both.

As noted above, DCDS 32 can be configured to take an incoming medicalimage file and automatically convert it for distribution to and viewingby any of a plurality of output modalities. FIG. 3 is a flow chartillustrating one example embodiment for an automated message creationoperation performed by DCDS 32 in accordance with one embodiment. In theexample of FIG. 3, it is assumed that destination information, e.g.,output modality information is included in a medical image file receivedby DCDS 32. In other embodiments, a user can access DCDS 32, e.g.,through GUI 208 and specify which files should be sent to which outputmodalities; however, a powerful aspect of DCDS 32, as configured inaccordance with the systems and methods described herein, is its abilityto automatically determine the destinations and to convert and formatthe data appropriately as described below.

In step 320, a file is received and the headers associated therewith areexamined to determine various information. The medical image filereceived by input 203 will often include metadata that providesinformation related to the medical data or images included therewith.For example, in a DICOM file, the medical image file will include aheader that comprises a plurality of fields. These fields are generallythe same for each input modality 10. Thus, DCDS 32 can be configured toexamine the header fields to determine various information as describedin detail below and with respect to FIG. 4.

In step 322, an output destination type, or modality can be determined.For example, the header can include information identifying recipientsof the images included in the image file. Or more specifically, theheader can include information identifying output modalities associatedwith various recipients or services, e.g., such as an online photo albumpage, site, or service; a social networking page or service, a mobiledevice, etc. Basic types of destinations can include a mobile device,such as a cellphone; an email account; a Web-Application SpecificInterface (API), e.g., associated with an online site or service, etc.Thus, DCDS 32 can be configured to examine the header file and determineassociated output devices or services, i.e., modalities.

Whenever possible, DCDS 32 can be configured to then retrieve specificcharacteristics of each destination type as indicated in step 324. Thesecharacteristics can include capabilities and physical characteristics ofthe destination device and specifications and limitations of the networkclass and message type. This information is then used to determine theoutput formatting and other specifications needed for each outputmodality. For example, this information can be used for adaptations ofthe image data based on specifications for the type of message beingsent, e.g., e-mail has limitations in specification and common practicethat can be adapted for; and MMS has very different limitations that canbe adapt for.

The capabilities and characteristics determined in step 324 can includeframe size, i.e., pixel dimensions of an image or video, e.g., 640 by480 and the like; data rate or data size, e.g., MMS messages cancommonly not exceed 300 KB total size, e-mail attachments exceeding 10MB are often not accepted, etc.; supported encoding format, e.g. mpeg 4,jpeg, etc.; and message layout rules, i.e., how a message can becomposed for the destination, e.g. MMS is made of “pages”, each able todisplay a single image or video and a single text along with playingaudio while e-mail is capable of HTML layouts and can hold attachmentsof any file type, etc.

In step 326, a basic compatibility check can be performed to determinewhether the data included in the image file can be delivered in a formatcompatible with the output modality. For example, if the image dataincludes video data, then a determination can be made as to whether theoutput modality is capable of receiving and displaying video data.

The most suitable delivery format is then chosen in step 328 to ensurethe output message that is ultimately generated includes the bestquality data that the output modality can handle. This can be importantfor example in clinical settings or settings where the data is beingused for examination or diagnostic purposes. Resolution informationsuitable for diagnostic purposes and the ability of DCDS 32 to providesuch resolution is discussed in detail below.

Then, in step 330 the data can be extracted and converted as required.For example, MMS messages allow only a very limited total message size.Therefore images or video in particular often need to be adapted andoptimized to let the final message meet the format and specificationrequirements of a particular output modality. In contrast, e-mailmessages often have no strict limit on size and therefore can acceptlarger files, e.g., higher resolution images or video. But even e-mailaccounts can include rules limiting extremely large files and thereforeeven e-mail messages can require optimization of, e.g., video files toensure sufficient quality but also to comply with size limitations.

If the incoming file is already encoded in a format compatible with theoutput modality, then often no conversion will occur in step 330 inorder to preserve the highest possible image quality.

In step 332, the data can be anonymized as required by any applicableanonymization rules. For example, the data can be extracted and copiedinto a generic format so that certain data can be removed, redacted,etc. The data can then be converted to the final output format. Steps330 and 332 can be performed in parallel or reverse order as required bya particular implementation.

In step 334, the converted data can then be assembled into an outputmessage in accordance with the applicable formats and specificationsdetermined in the preceding steps. Optionally, other data can beincluded with the message. This information can be manually entered,e.g., via GUI 208 or it can be extracted from the metadata accompanyingthe received file. Still further, the data can be data retrieved fromconfiguration settings based on the set of characteristics describedabove.

In certain embodiments, the data components that are to comprise anoutput message are assembled according to template rules for the type ofmessage being created. For example, the various template rules can bestored in Storage System 214 and accessed by Output Module 213 in orderto assemble the output message. For example, MMS messages are based on apage metaphor where each page can contain an image or video, a textelement, and an audio element. Thus, sending two or more images, orincluding text, audio, or both with the image(s) will then require themessage to be assembled into several pages. By contrast, e-mail messagescan include any number of images, attachments, etc., depending on, e.g.,the message size restrictions.

Output Module 213 can then be configured to elect the appropriate outputgateway for transmission of the assembled output message in step 336.For example, Output Module 213 can be configured to send an e-mailmessage to a SMTP server (not shown) and to send an MMS message to a MMSgateway (not shown).

FIG. 4 is a flow chart illustrating example type of information and datathat can be examined in step 320. As can be seen in FIG. 4, when thefile comes in, the metadata or more specifically the header can beexamined to identify the input modality in step 420. In step 422, thecompatibility of the modality determined in step 420 with the system canbe determined. If compatible, then in step 424, specific characteristicsof the data included in the image file can be determined. For example,whether or not the file actually includes any image or video data orwhether the data is simply report or measurement can be determined instep 424. When an incoming file does include, e.g., report ormeasurement data, then such information can be extracted and stored in,e.g., a generic structured format in step 426. In step 428, any imagedata can then be extracted and stored as well and variouscharacteristics can be determined such as binary encoding format, framesize, color bit depth, still image or video, etc.

FIG. 5 is a flow chart illustrating an example process for the use ofinformation embedded inside of the metadata including with incomingfiles by DCDS 32 in accordance with one embodiment. The metadata, e.g.,header fields can be used to ensure safe and secure delivery of theimage data included therewith. For example, a DICOM image file caninclude a plurality of header fields that are key-value pairs in anumber of datatypes, such as strings, numbers, dates, specialmeasurement types, etc. Fields can be embedded in the and can be hardlinked to the file for which the provide metadata. In this way, there isno way to mix-up header files and the associated data, since they arenot separated.

In step 520, DCDS 32 can be configured to automatically track and recordheader fields for each network device sending images. In this way, DCDS32 can identify the specific device associated with an incoming file.DCDS 32 can do this by recording which header fields are present for aparticular modality 10 in step 522 and to then record the data includedin device-dependent header fields for the associated modality in step524. A particular device should always report the same values for, e.g.,manufacturer, model name, model number, etc. Thus, DCDS 32 can use thisinformation to identify a particular device.

In step 526, DCDS can detect any changes in the data and then takeappropriate action. For example, changes to header field data thatshould not be changed, e.g., manufacturer information, can be anindication that the file has been tampered with or someone is trying tohack into the system. In response to detection of such changes, thesystem can log the event, notify an operator, place the incoming data inan approval queue, quarantine the data or any further data from theassociated device, reject the data, rejecting the all future data fromthe device, to name just a few possible actions.

In step 528, DCDS can be configured to search the header fields for datathat can identify an intended recipient as noted above. Identificationcan be in the form of an actual, e.g., e-mail address, mobile stationInternational Subscriber Directory Number (ISDN), web site address, etc.In fact, such direct identification can be preferable as it takesadvantage of the existence of the header fields. Identification can alsobe indirect such as an ID that can be used to look up a direct address,e.g., in a registry stored in storage system 214. It should also benoted that each field can include more than one piece of data and dataof different types. Accordingly, any identifying or address fields caninclude telephone numbers as well as e-mail address, etc. Further,identifying data can be included in more than one field.

The DCDS 32 can be configured to then determine an action to take instep 528 based on any identifying data detected in step 530. Suchactions can include sending an appropriate message to any addressesfound, formatting messages appropriately as described above, notifyingan operator, adding a message to a queue, e.g., for manual approval,locating and adding other data or information to an outgoing message, toname just a few.

Accordingly, FIG. 6 is a flow chart that illustrates the operation ofDCDS 32 in more detail. Referring to FIG. 6, a Conversion Request 301can be received containing, at a minimum, an internal identifier for theimage, and a destination format. As noted above, the conversion requestcan be the result of information and data included in the metadataassociated with an incoming file. As noted below, however, the requestcan also result from input received through GUI 208. Optionally, therequest could contain new image dimensions to be scaled as output imageto be sent. The Image Converter 211 can be configured to then determinethe existence of the requested image 304 by trying to locate themetadata associated with it in metadata database 303. If no recordexists for the requested image, the converter can optionally return aplaceholder image (305, 308) or abort the conversion attempt 306. Aplaceholder is typically an image, video or similar media communicatingthat the requested image is unavailable. At this point, the converteralso can also be configured to determine if the requested output formatis feasible or not.

If a metadata record in database 303 does exist, then the converter canbe configured to load the, e.g., DICOM image 307 from image storage 302into a raw binary format. The Converter 211 can be configured to thendetermine if the image data should be resized to the dimensions providedin the request or to the dimensions required by the requested outputformat. For example a jpeg preview for the Web GUI 208 could be renderedin any dimensions that are suitable to the layout of the html document,while video for MMS messages have very specific dimensions to complywith the specification.

Next, the image data can be converted 311 to the requested destinationformat. The results can be saved to an image cache 312 and metadatarecords can be updated 313 to indicate the existence of the convertedimage. Finally, the converted images can be returned as a response tothe request. Converter 211 can then return either the converted binarydata directly or return a reference to its location in the image cache313.

As noted, DCDS 32 can also be operated and interfaced with through theWeb GUI 208. GUI 208 can enable both remote and local access the DCDS 32and allows for images to be located within storage system 208. Theimages may need to be located or analysis or diagnosis or for sending toa specified destination or address.

Two primary ways for accessing files can be provided. The first wayinvolves finding files without any identifying information. This isexplained in detail with respect to FIG. 7; however, it should first benoted that each device sending files to DCDS 32 can be identified byrecording and mapping header fields of incoming file transfers. Thedevices can also be at least partially identified based on their networkaddress, AE titles used for the transfer, or both. Each device can thenbe given a name that is unique and preferable meaningful to operators.Files as well as their series, study, or both, can then be identified bythe device they originated from, the time and date of the image capture,and header fields identifying the operator of the device used to capturethe images.

Since no patient information is needed, DCDS 32 can handle anonymizeddata and no patient information can be gathered by the misuse of thesystem. Further, the most used images can be stored as the most recentimages in the system. Thus, finding images can be made very efficient inthis manner. Once the file, series, study, etc., had been found, GUI 208can offer the operator direct access to features for viewing the images,sending the images, etc.

With this in mind, FIG. 7 is a flow chart illustrating a typical use ofthe Web GUI 208 and its streamlined interface for finding an image bythe originating modality without any identifiable patient information(401-404) in accordance with one embodiment. When an image has beenidentified (405,) the interface displays a service request form wherethe user enters output destination information and other messagedetails. If the data validates (407,) the required conversions arerequested (408) from the Image Converter (211.) For all successfulrequests, the data is assembled by the appropriate output plug-ins(409-411,) and the results are sent (412-414) to the appropriatedestinations. Status information for each individual output is gathered(415,) and returned (416 or 417) to the form view (405) for display. Atthis point, the user can choose to repeat the send process or return tofinding another image.

The Web GUI 208 allows for sending groups of images that belong to thesame, e.g., DICOM Series. The operating steps are similar to thoseillustrated by FIGS. 7 and 8. The Web GUI 208 also present interfacesfor configuring the Event System 209, organizing and storing outputdestination addresses and other administrative tasks necessary. It isimportant to note that, as a security measure, the Web GUI 208 does nothandle any authorization of source modalities allowed to store images oraccess privileges to those images. These important settings are onlyavailable through a separate method of access either locally orremotely. With the DCDS running on a Unix-style operating system, remoteaccess would typically be via the Secure Shell (SSH) protocol. If theDCDS is running on a Windows operating system, remote access wouldtypically be via Terminal Services. Both protocols are examples ofsecured remote access to the operating system.

The second way to access files is to use identifying information. Forexample, operators can search for files using patient information suchas name, birth date, patient ID, etc. The operator can, for example,input a search term and if there is a match, the system can present allavailable studies. If multiple patients are returned, then they can bepresented for selection. Once the patient is selected, and theassociated file, series, study, etc., had been found, GUI 208 can offerthe operator direct access to features for viewing the images, sendingthe images, etc.

FIG. 8 is a flow chart illustrating a variation of the typical use ofthe Web GUI 208 and its streamlined interface for finding an image byusing a piece of identifiable patient data (501-504,) such as, patientname, and birth-date, etc. Alternatively, any unrelated identifyingpassword or PIN code can be utilized to avoid using real patientinformation to ensure patient privacy. After that, the processing stepsas described above related to FIG. 7 can be followed.

In certain embodiments, CCS 30 can be interfaced with a server 902 thatcan be configured to host and support various value added services for,e.g., patients and family in relation to the images being captured bymodalities 10 as illustrated in FIG. 9. For example, if the images arefetal ultrasound images, the server 902 can be configured to provide avariety of services for the parents, family, friends, etc. For example,the DCDS 32 can be configured to convert the images to a proper formator formats supported by server 902 and the related services. The imagescan be sent to server 902 and stored in storage system 904.

It will be understood that server 902 can actually comprise a pluralityof servers, computers, routers, etc., as well as the appropriatesoftware and firmware required to carry out the functions describedherein. Further, storage system 904 can comprise one or more databases,one or more storage servers, as well as other physical storage mediumsas required.

Server 902 can then be configured for example, to host a web site onwhich users can create accounts. The users can then access the images onthe site and purchase images, pregnancy calendars, customized mugs, keychains, T-shirts, canvases, etc. Further, the site can be configure topresent pictures, illustrations, information on fetus and childdevelopment, health and nutrition tips, etc. Such a site can enable suchservices as a registry, e.g., for a baby shower; automatic updates tofriends and family; digital and viral gifts, such as baby images withdigital lullabies; invites and thank you cards; etc.

A user can be charged a fee for setting up an account, e.g., asubscription fee, either one time or periodic, the user and family andfriends can also be charged for the various products and services, orboth.

In addition, kiosks 908 can be set up, e.g., in maternity wards that canprovide at least some of the same services. Kiosk 908 can either bestand alone, i.e., interfaced directly with CCS 30, or can be interfacedwith server 902 as illustrated. Thus, family and friends can orderpictures and other goods, e.g., right in the waiting room.

Further, the user can continue to use the account even after the birthof the child. For example, the site can track the child throughout itschild hood, or at least through the first few months or years. The sitecan be configured to send birthday reminders and announcements tofriends and family or to inform of other special events, developmentalmilestones, etc. Moreover, the site can be configured to continue topresent developmental information as well as health and nutrition tipsfor both mother and child.

In fact, it can be preferable to have the parent upload contactinformation for friends and family. In this manner, server 902 can beconfigured to continue to send birthday reminders to friends and family.In certain embodiments, the site hosted by server 902 can be affiliatedwith or host a “gift store” offering various products and services.Alternatively, or in addition, the site can offer discounts, coupons,etc., to various other business and stores. Since server 902 will havepertinent demographic information related to the child, e.g., residenceinformation, sex, age, race, and possibly even parents age, profession,and other affiliations, the site can send reminders, giftrecommendations, discount offers, etc., that are appropriate for thechild and the family, popular with similar demographics, etc.

In this regard, it can be preferable to offer the user the opportunityto provide such demographic information. Thus, in one embodiment, theuser can access the site and customize or provide profile information,contacts, preferences, etc. Algorithms running on server 902 can beconfigured to then use the information available to make productrecommendations, etc. In fact, since server 902 will have informationfor individuals all over the world, the algorithms can be configured touse information for populations that share similar demographics, incomelevels, preferences, etc., to make recommendations.

In certain embodiments, a user can purchase items through the site,i.e., through server 902. For example, server 902 can be configured toaccept credit card payment, a PayPal account, or for mobile billingThus, server 902 can be configured to process the transaction and eitherdeduct an appropriate fee or charge a related business, affiliate,partner, etc., a transaction fee. Moreover, purchase information canalso be fed into the algorithms and used to make future recommendations.In fact, the purchases of an entire related population can be used tomake more targeted and appropriate recommendations.

Thus, as a child grows, the algorithms can be constantly updated andhoned in order to make, e.g., gift recommendations. Recommendations thatcan be automatically sent out to friends and family over the years. Asthe database grows over time and with more and more users, thealgorithms can be honed to provide ever more relevant and targetedrecommendations.

It should also be noted that the database will necessarily include vastinformation about the relationships and connections between a largepopulation. This includes direct links such as friends and family, butalso more indirect links such as preferences, similar buying habits,etc. This type of interconnection information can be very valuable fortargeted advertising and product recommendations as well as for simplytracking and mapping the interconnectedness of a large population.

It should be pointed out that such a site can be built around otherconditions or events, such as a cancer support site, physical therapysupport site, etc. It should also be pointed out that the merging ofinterconnectedness data for these various other conditions and eventscan extend the power of the information and lead to even betteralgorithms for targeting information and products and services.

It should also be noted that users can access the site via, e.g., theInternet using computers 914 and mobile devices 912. Further, the sitecan be interfaced with other social networking sites such as Twitter,Facebook, etc. In certain embodiments, the site can actually beconverted to an application, or widget that can be exported to othersites. For example, a grandma can place the application on her Facebookpage and receive updates and notices more easily without needing to logonto server 902. This can increase the interaction with the site, whichcan increase, for example, the amount of information and data availableto server 902 as input to the algorithms described above.

While certain embodiments have been described above, it will beunderstood that the embodiments described are by way of example only.Accordingly, the systems and methods described herein should not belimited based on the described embodiments. Rather, the systems andmethods described herein should only be limited in light of the claimsthat follow when taken in conjunction with the above description andaccompanying drawings.

Peripheral Encryption and Conversion Device

In one embodiment, a peripheral device may be attached with a medicalimaging device for the encryption and conversion of a medical image intoa secure and standardized image file format as well as the communicationof the encrypted and/or converted image to a secure server on a remotenetwork. As shown in FIG. 10, the peripheral device 102 may be a dongleor other type of stand alone device which can be physically attachedwith a medical imaging device 101, and will have its own processor andmemory for executing a variety of functions relating to the conversion,encryption and transmission of medical image files from the medicalimaging device to a remote server 103 on another network. The peripheraldevice 102 may be attached with a communication port on the medicalimaging device, such as a network port, serial port or othercommunication interface. The peripheral device may act as a filter tomonitor all medical image files generated on the medical imaging deviceand encrypt and convert selected medical image files for transmission toa remotely connected device on another network, such as a server or amobile device.

The dongle may be configured with a separate network connection to alocal area network (LAN) or wide area network (WAN), or it may beconfigured to use the network that is already connected with the medicalimaging device. If the medical imaging device is not connected to anetwork or is connected to a network that is not capable of transmittingmedical images, the dongle may have network hardware to allow the dongleto communicate over a WiFi or cellular network or even accept a directEthernet cable connection to a local network which the medical imagingdevice is not connected with.

In another embodiment, the encryption dongle 102 may be connected withthe imaging device 101 with an insecure connection, in which case theencryption dongle 102 will function to take medical images stored on themedical imaging device 101 and encrypt the images for transmissionacross a secure network connection to a remote device, such as a remotesecure server or a mobile device that is the ultimate destination of themedical image.

One embodiment provides a method and technical system for encrypting androuting DICOM network connections from devices without any suchencryption capabilities built-in.

One embodiment of the invention can listen on known ports forunprotected communication and automatically encrypt and route theconnection in its encrypted form over the port's encrypted counterpart.E.g. ordinary DICOM connections on TCP port 104 or 11112 can beencrypted in SSL/TLS and routed as DICOM/TLS on TCP port 2762. Thiswould effectively make the connection appear to the remote server as asecure TLS connection and to the client device as an unprotectedconnection. By attaching the embodiment of the invention to the networkport of an imaging device or as a network router on the same protectedlocal network as the device, a high level of security is maintained.

Likewise, ordinary “web” connections over the HTTP protocol on TCP port80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. Thiswould effectively make the connection appear to the HTTP server as asecure HTTPS connection and to the HTTP client as an unprotectedconnection. It should be noted here that encrypting HTTP traffic isuseful only with older clients and servers which are capable of secureconnections. It is, however, a well-known pair of network ports thatserve to illustrate a general embodiment of the invention.

Embodiments of the invention include a wireless network connection suchas WiFi or cellular modem capabilities to not only encrypt but also tooffer access to the Internet without existing network infrastructurenear the imaging device. This is highly useful for portable devices thatcan be used on-the-go running on battery power.

Embodiments of the invention can be pre-configured to only forwardprotected traffic to a single remote end-point.

Embodiments of the invention may use any and all relevant encryptionmethods to secure the connection. Examples or these include theaforementioned SSL/TLS standard as well as other common encryptionstandards. The point being that the invention will mimic the nativeencryption standard for each type of connection an embodiment supports.Encryption may be encoded and decoded either by dedicated chips(electronic hardware components), software or a combination of softwarewith hardware acceleration.

Network Encryption and Conversion Device

A network device for connection with a local network including at leastone medical imaging device provides for the encryption and conversion ofa medical image from the at least one medical imaging device into asecure and standardized image file format, as well as the communicationof the encrypted and/or converted image to a secure server on a remotenetwork. The network device may act as a router or a gateway on thelocal network to monitor traffic of medical images from the medicalimaging devices to destination devices outside of the local network andensure that the medical data files are encrypted and converted into anappropriate format for delivery to a device on the remote network. Upondetection, the network device will encrypt and convert the selectedmedical image files for transmission to a remotely connected device onthe remote network, such as a server or a mobile device.

One embodiment of the network device is illustrated in FIG. 11, wherethe network device 104 acts as an encryption router to receive medicalimage files from one or more medical imaging devices 101 over a localnetwork which may not be secure. The encryption router 104 will then beconfigured for encryption and conversion of a medical image into asecure and standardized image file format. The encryption router 104will then be configured for communication of the encrypted and/orconverted image over a secure connection to a secure server 103 on aremote network, such as the Internet.

In one embodiment, the network device 104 will create a private networkfor the one or more medical imaging devices 101 to communicate. Thenetwork device 104 may then transmit an encrypted DICOM image over WiFi,cellular (3G) or cable connection to a remote network. In thisconfiguration, the network device 104 acts as the network gate to ensurethat all medical images being transmitted out of the local network areconverted and encrypted.

FIG. 12 illustrates a flowchart of the data flow of a medical image filefrom a local area network (LAN) 301 to a remote device on a remote widearea network (WAN) 307. The network device 104 may include one or moreof the components illustrated herein, including an encryption listeningport 302 which monitors network traffic in the LAN for the transmissionof medical image files which are not encrypted or converted into aproper format. An encryption database 305 may store encryption settingsthat provide instructions on the type of encryption that a particularmedical image file should be encrypted with, perhaps depending on thetype of network or the destination device on the remote WAN network 307.The medical image file is processed 303 to encrypt the file, after whicha port is mapped 304 for transmission of the file. The encrypted file isthen transmitted through a firewall or other local router 306 to aremote WAN network 307.

In one example, a Vscan imaging device captures a medical image that isnon-DICOM and not encrypted, but which is selected for transmission fromthe Vscan to a remote secure server on the remote network. The medicalimage is then sent to the network device 104, which converts the imageto a DICOM image and encrypts the image before sending it to the remotesecure server.

The network device may be useful in a local network which is otherwiseinsecure or unreliable, as it creates a secure connection with themedical imaging devices and with a remotely connected server or deviceon another network. Additionally, the network device may be useful inhighly secure networks with strict firewalls that would otherwiseprevent connections to a remote secure server.

In one embodiment, the network device may be configured as a networksatellite which is attached with the local network but which acts as aremote secure server to that the one or more medical imaging devicessends the images to the network satellite under the impression that thenetwork satellite is the final destination for the medical image file.The network satellite will then take the medical image and encrypt orconvert it (or both) and then send the encrypted and converted image tothe actual remote secure server. In this embodiment, the medical imagingdevice does not need to be instructed to send the medical image file toa new location on the network such as the network device, as it insteadtransmits the file to what it believes is the final destination of themedical file—the remote secure server on a remote network.

One embodiment provides a method and technical system for encrypting androuting DICOM network connections from devices without any suchencryption capabilities built-in.

One embodiment of the invention can listen on known ports forunprotected communication and automatically encrypt and route theconnection in its encrypted form over the port's encrypted counterpart;e.g., ordinary DICOM connections on TCP port 104 or 11112 can beencrypted in SSL/TLS and routed as DICOM/TLS on TCP port 2762. Thiswould encrypt the data over a secure connection, while effectivelymaking the connection appear to the remote server as a secure TLSconnection and to the client device as an unprotected connection. Byconnecting this embodiment of the invention to the network port of animaging device or as a network router on the same protected localnetwork as the device, a high level of security is maintained.

Likewise, ordinary “web” connections over the HTTP protocol on TCP port80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. Thiswould effectively make the connection appear to the HTTP server as asecure HTTPS connection and to the HTTP client as an unprotectedconnection. It should be noted here that encrypting HTTP traffic isuseful only with older clients and servers which are capable of secureconnections. It is, however, a well-known pair of network ports thatserve to illustrate a general embodiment of the invention.

Embodiments of the invention include a wireless network connection suchas WiFi or cellular modem capabilities to not only encrypt but also tooffer access to the Internet without existing network infrastructurenear the imaging device. This is highly useful for portable devices thatcan be used on-the-go running on battery power.

Embodiments of the invention can be pre-configured to only forwardprotected traffic to a single remote end-point.

Embodiments of the invention may use any and all relevant encryptionmethods to secure the connection. Examples or these include theaforementioned SSL/TLS standard as well as other common encryptionstandards. The point being that the invention will mimic the nativeencryption standard for each type of connection protocol an embodimentsupports. Encryption may be encoded and decoded either by dedicatedchips (electronic hardware components), software or a combination ofsoftware with hardware acceleration.

Encryption and Conversion Plugin

Systems and methods for encrypting and converting medical image files ona device within a network are provided. An encryption and conversionunit may be incorporated within the hardware and software of a medicalimaging device or another network device in order to provide thecapability for encrypting a medical image for transmission to a remotenetwork and for converting the medical image to a format that iscompatible with a destination device or network. The encryption andconversion unit may also be configured to package and transmit aconverted and encrypted image to an appropriate destination, such as asecure server, on a remote network.

The encryption and conversion unit may act as a router or a gateway onthe local network to monitor traffic of medical images from the medicalimaging devices to destination devices outside of the local network andensure that the medical data files are encrypted and converted into anappropriate format for delivery to a device on the remote network. Upondetection, the encryption and conversion unit will encrypt and convertthe selected medical image files for transmission to a remotelyconnected device on the remote network, such as a server or a mobiledevice.

One embodiment of the encryption and conversion unit is illustrated inFIG. 13, where the encryption and conversion unit 104 acts as anencryption router to receive medical image files from one or moremedical imaging devices 101 over a local network which may not besecure. The encryption and conversion unit 104 may be incorporatedwithin each medical imaging device 101 as software, hardware or acombination of software and hardware. In another embodiment, theencryption and conversion unit 104 may be a part of a router, gateway,firewall or other network device which monitors and regulates trafficover a network. Regardless of the type of device in which it is placed,the encryption and conversion unit 104 will then be configured forencryption and conversion of a medical image into a secure andstandardized image file format. The encryption and conversion unit 104will then be configured for communication of the encrypted and/orconverted image over a secure connection to a secure server 103 on aremote network, such as the Internet.

FIG. 12 illustrates a flowchart of the data flow of a medical image filefrom a local area network (LAN) 301 to a remote device on a remote widearea network (WAN) 307. The encryption and conversion unit 104 mayinclude one or more of the components illustrated herein, either assoftware, hardware or a combination of both. In one embodiment, theencryption and conversion unit 104 includes an encryption listening port302 which monitors network traffic in the LAN for the transmission ofmedical image files which are not encrypted or converted into a properformat. An encryption database 305 may store encryption settings thatprovide instructions on the type of encryption that a particular medicalimage file should be encrypted with, perhaps depending on the type ofnetwork or the destination device on the remote WAN network 307. Themedical image file is processed 303 to encrypt the file, after which aport is mapped 304 for transmission of the file. The encrypted file isthen transmitted through a firewall or other local router 306 to aremote WAN network 307.

In one example, a Vscan imaging device captures a medical image that isnon-DICOM and not encrypted, but which is selected for transmission fromthe Vscan to a remote secure server on the remote network. Theencryption and conversion unit 104 is embedded as software running onthe Vscan device, and therefore converts the image to a DICOM image andencrypts the image before sending it out of the Vscan device to theremote secure server.

The encryption and conversion unit may be useful in a local networkwhich is otherwise insecure or unreliable, as it creates a secureconnection with the medical imaging devices and with a remotelyconnected server or device on another network. Additionally, the networkdevice may be useful in highly secure networks with strict firewallsthat would otherwise prevent connections to a remote secure server.

One embodiment provides a method and technical system for encrypting androuting DICOM network connections from devices without any suchencryption capabilities built-in.

One embodiment of the invention can listen on known ports forunprotected communication and automatically encrypt and route theconnection in its encrypted form over the port's encrypted counterpart.E.g. ordinary DICOM connections on TCP port 104 or 11112 can beencrypted in SSL/TLS and routed as DICOM/TLS on TCP port 2762. Thiswould effectively make the connection appear to the remote server as asecure TLS connection and to the client device as an unprotectedconnection. By having the embodiment of the invention communicate withthe network port of an imaging device or with a network router on thesame protected local network as the device, a high level of security ismaintained.

Likewise, ordinary “web” connections over the HTTP protocol on TCP port80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. Thiswould effectively make the connection appear to the HTTP server as asecure HTTPS connection and to the HTTP client as an unprotectedconnection. It should be noted here that encrypting HTTP traffic isuseful only with older clients and servers which are capable of secureconnections. It is, however, a well-known pair of network ports thatserve to illustrate a general embodiment of the invention.

Embodiments of the invention include a wireless network connection suchas WiFi or cellular modem capabilities to not only encrypt but also tooffer access to the Internet without existing network infrastructurenear the imaging device. This is highly useful for portable devices thatcan be used on-the-go running on battery power.

Embodiments of the invention can be pre-configured to only forwardprotected traffic to a single remote end-point. Embodiments of theinvention may use any and all relevant encryption methods to secure theconnection. Examples or these include the aforementioned SSL/TLSstandard as well as other common encryption standards. The point beingthat the invention will mimic the native encryption standard for eachtype of connection an embodiment supports. Encryption may be encoded anddecoded either by dedicated chips (electronic hardware components),software or a combination of software with hardware acceleration.

Mobile Device Implementation of the Encryption and Conversion Unit

In certain embodiments, the encryption and conversion functionalitydescribed above, e.g., with respect to FIGS. 10-13, can be implementedon a mobile device such as a smartphone, tablet or other mobile device.This embodiment is illustrated in FIG. 26, wherein the encryption andconversion unit 105 of, e.g., FIG. 13 is replaced by a mobile device 107on which software 109 has been installed that allows the mobile deviceto perform the encryption and conversion functions, as well as therouting functions, described above.

In many embodiments, the encryption and conversion functionality can beintegrated with the mobile device 107 by downloading an application 111to the mobile device 107. The application 111 will then include—or willallow the user to download—the software 109 needed to perform therequired functions. The software 109 can thus be compiled for theprocessor architecture of the mobile device 107.

Software 109 can then act as a router or tcp proxy through which thedata sent from devices 101 (e.g., image modalities such as a portableultrasound machine) travels. From the ultrasound machine's point of viewit will seem as if it is communicating directly with a DICOM server onthe mobile device 107, but it will actually be communicating directlywith hosted server 103 through the encrypted tunnel or secure connectionprovided by mobile device 107.

In one embodiment, the port used by mobile device 107 will often be portnumber 104, but there is also the alternate port number 11112, which isused whenever there is a need to stay above port 1024 (although this israrely the case).

In certain embodiments, the software can require payment for either onetime uses or a subscription. Thus, the system can be configured suchthat certificates can be provided, e.g., by the server 103 to thesoftware 111. Typically the certificates would be set to expire; thusapplication 109 can enable a process where the customer pays to reissuethe certificate and extend the period during which the certificate isvalid. This could be simply called “the subscription.” The autoexpiration may be quite useful in this scenario. Thus, application 109can include an ability to fetch the new certificate and install itautomatically.

Application 109 can include payment capability that can allow the userto pay—using a credit card, mobile wallet, or other account—for asubscription or one time use; e.g., an extended or new period duringwhich the software would have valid certificates.

In certain other embodiments, a more advanced user interface can beincluded in application 109 that allows the user to actually interact,monitor and troubleshoot the functionality of software 111. This caninclude the ability to verify connectivity, the existence of the secureconnection, upload and download speeds, etc.

In certain embodiments, mobile device 107 and the imaging devices 101can communicate via wireless communication links, such as NFC,BlueTooth™, or WiFi. Thus, a communications dongle (not shown) can beinterfaced with the devices 101 to enable such wireless communication,or such capability can be included in the device 101.

The mobile device 107 can in turn communicate with the server 103 over anetwork, e.g., 3G/4G WAN systems. In other embodiments, however, mobiledevice 107 is also able to use another wireless communication protocol,e.g., a WiFi connection, to communicate with the server 103. This meansthat, for example, a tablet without 3G/4G capabilities can still act asan encryption device by connecting the tablet over WiFi to a localnetwork (reachable by any modalities 101 that will be using it).

If, for example, imaging devices 101 have Wi-Fi or other wirelesscommunications capabilities and mobile device 107 is using a wirelessWAN to communicate with server 103, mobile device 107 can act as a Wi-Fibase station and router to which the imaging device 101 (e.g., anultrasound machine) connects. The IP address to which the ultrasoundmachine 101 connects is that of the mobile device 107, which is the sameas whatever router IP address the ultrasound machine gets when itconfigures itself via DHCP.

Integrating Image Management

Systems and methods for integrating a variety of communication protocolsand file types relating to medical imaging are provided. The systemintegrates a current interface with third party software by addingsoftware and intelligence to the current interface to provide forcommunication with third party image management software.

In one embodiment of the integration software, a medical imaging userinterface such as a GE Viewpoint interface generates a plurality ofmedical images in a portable document format (PDF). The systems andmethods described herein will then convert the PDF documents into DICOMformatted image documents, which may then be sent to a specificdestination and then converted back into a PDF for viewing on anappropriate electronic device, such as a personal computer, portableelectronic device, etc.

In another embodiment, an HL7 protocol device is used for medicalsoftware communication, and it includes a packet on the destination of aparticular document. For example, an image created by an HL7 deviceneeds to be sent to a doctor or patient. The integration softwareobtains information on the image, combines it with the commandinformation on the destination for the image, and then adds it to aDICOM message.

The integration software works by obtaining information needed from thethird party software system and determining information needed toconvert, encrypt and send the images to the appropriate destination.

Real-Time Remote Interaction

The systems and methods described herein provide for live, or real-time,remote diagnosis of a medical problem of a patient using one or moremedical images of the patient taken with a medical imaging device, suchas an MRI. The system may be embodied as a network with a plurality ofcomputing and display devices which displays a graphical user interface(GUI) to each user so the users can all view the same medical images inreal-time. The users are also provided with options to annotate theimages in real-time, chat about the images through an instant messagingprogram and even talk using a voice-over-internet-protocol (VOIP) or atraditional landline conferencing system. The system provides aplurality of menus for a user to organize images, select diagnoses andother actions, and otherwise collaborate with a plurality of users inreal-time to make a medical diagnosis based on one or more medicalimages.

FIG. 16 illustrates an overall workflow for the real-time remoteinteraction, where a user is first presented with a dashboard, or homescreen, showing various options for collaborating to make a diagnosis.The dashboard is further illustrated in FIG. 18. Medical images from aVscan device may be shown to the user, and an Exam Screen process maythen be undertaken. During the exam screening, the images may be sent toa patient, an examination may be sent to the patient, and the resultinginformation may be sent for diagnosis. A live, or real-time, diagnosismay then be made. In a true emergency situation, the flowchartillustrates that these steps may be skipped in order to make anemergency diagnosis without collaborating with remote users.

FIG. 17 illustrates an overall GUI which the user is presented with whenviewing a display of a computing device on a network. A main menu, amain content area and a navigation and information section may all beprovided.

FIG. 18 illustrates a “dashboard” GUI, which will list the medicalimaging devices that are connected to the overall network or with theuser's actual computing device (such as the medical imaging devices onthe user's local network at a hospital or medical facility). Thedashboard will also list the images that have been captured by thosedevices, and may arrange them in order of capture, by patient, bydoctor, etc. If new images arrive, they may be moved to the top of thelist and highlighted so the user can easily find them. In oneembodiment, when a new image or images is captured by a particulardevice, an alert will go out to the appropriate physician or health careprovider handling that patient's case—such as an SMS or e-mail message.The dashboard may also provide a search feature where the user cansearch through the images and a database of information related to theimages and the patients.

FIG. 19 shows further detail of the main menu GUI, which provides:options to select DICOM images (where the main image workflows arefound); and Inbox where the user will receive messages from the systemor other users; a Recipients icon of patients or other users andcontacts that can be easily found and contacted for sending images andmessages; a Settings icon to handle setup of imaging devices,anonymization or automation of patient messages and labels to categorizestudies; a Statistics icon to show traffic through the overallapplication over time; an Administration icon to show whereadministrators manage user accounts and setup branding of patientimages; an Account icon where non-administrators can review theirprofiles and other account details; and a Sign Out icon that allows auser to sign out of the system. One will appreciate that the icons andoptions listed here are may be altered and are not limited to thosedescribed.

FIG. 20 illustrates one embodiment of an image workflow, where an imageor a study of images can be selected from a list for further review. Thestudy information may include the number of files and labels assigned toeach study, as well as the number of comments made on particular studiesand images by other users. Different icons for still images, videos,comments, etc. may be provided. The labels may pertain to suggesteddiagnoses or to a particular type of image or images contained withinthe study.

FIG. 21 illustrates a series of images as thumbnails that can be quicklyreviewed before selecting one or more of them for further review. A listof actions is provided at the top of the GUI, and other icons on thethumbnails provide indications as to whether the thumbnail represents avideo and whether it is of a particular image format (such as DICOM).The user may click or select one of the thumbnails to open the fullimage or video.

FIG. 22 is an illustration of a real-time remote interactivecollaboration GUI, where a medical image is displayed along withannotations that are made on the image by one or more users. A chatscreen is shown where the users can type instant messages to each otherin the process of discussing the diagnosis of the patient, and a list ofthumbnails of other images in the study may be provided at the top. Thethumbnails may be updated as new images arrive. This “Live DiagnosisScreen” is a real-time collaboration tool that updates all informationin real-time and synchronizes edits between users, including theannotations, chats, actions, selected images, pins and other changes.The live diagnosis screen may be particularly advantageous for anemergency room situation where a diagnosis is needed immediately. In thechat screen, the users have the option of inviting additionalparticipants and taking one or more other actions related to the case.

FIG. 23 illustrates one embodiment of the Actions that may be selectedin the chat screen, and may be a way to provide unambiguous instructionsto another user—such as a doctor or nurse who is providing care to thepatient. The Actions tab may also provide tracking of the selectedactions and who executed and suggested the actions so that the treatmentof the patient can be properly documented. In the Invite Collaboratorstab, a user can invite more users to participate in a live diagnosisprocess. The invited users may receive a text message, email or phonecall asking them to join in the live chat session. The user interfacemay be adopted for any type of computing device, including mobile phonesand tablets, to allow other users to participate from any location andwith any type of portable electronic device.

FIG. 24 illustrates a GUI where a diagnosis can be requested for aparticular patient based on a set of images. The user can selectdifferent options for concerns and possible diagnoses to beinvestigated. When the request is sent, one or more users may beinformed via email, text or phone, and an inbox screen may be providedto show when replies arrive.

In FIG. 25, the GUI for making a diagnosis is provided, where severalimages and a plurality of menus are provided to select appropriatediagnoses. The images may be downloaded to a computer desktop for moredetailed viewing with other software tools. Options for potentialdiagnoses can be highlighted or selected. Once a final decision isreached, the diagnosis is sent and recorded in the record for futurereview and study.

What is claimed is:
 1. A system for mobile encryption and conversion ofa medical image, comprising: a medical imaging device which captures atleast one medical image in a medical image file format, wherein themedical image file also includes metadata with information on adestination for the medical image, and wherein the information on thedestination for the medical image is received via a user interface onthe medical imaging device; a mobile device which receives the medicalimage file from the medical imaging device, converts the medical imageto a standardized image file format compatible with the destinationbased on the information on the destination for the medical imageobtained from the metadata, and encrypts the converted medical imagefile; and a server which receives the encrypted medical image file fromthe mobile device and transmits the medical image file to thedestination for the medical image file.
 2. The system of claim 1,wherein the medical image file format is a Digital Imaging andCommunications in Medicine (DICOM) format.
 3. The system of claim 1,wherein the mobile device communicates with the medical imaging deviceover a wireless network.
 4. The system of claim 1, wherein the mobiledevice communicates with the server over a wireless network.
 5. A mobileconversion and encryption device, comprising: a communication interfacewhich receives a medical image file in a medical image file format froma medical imaging device, the medical image file including metadata withinformation on a destination for the medical image; a conversion unitwhich converts the medical image to a standardized image file formatcompatible with the destination based on the information on thedestination for the medical image obtained from the metadata; anencryption unit which encrypts the converted medical image file tocreate an encrypted medical image file; and a transmission unit whichtransmits the encrypted medical image file to at least one destinationvia the communication interface.
 6. The mobile device of claim 1,wherein the medical image file format is a Digital Imaging andCommunications in Medicine (DICOM) format.
 7. The mobile device of claim5, wherein the mobile device communicates with the medical imagingdevice over a wireless network.
 8. The mobile device of claim 5, whereinthe mobile device communicates with the destination over a wirelessnetwork.
 9. The mobile device of claim 1, wherein the transmission unittransmits the encrypted medical image file to a hosted server over anetwork.
 10. A method of encrypting and converting a medical image witha mobile device, comprising: capturing at least one medical image in amedical image file format with a medical imaging device, wherein themedical image file also includes metadata with information on adestination for the medical image, and wherein the information on thedestination for the medical image is received via a user interface onthe medical imaging device; receiving the medical image file at a mobiledevice from the medical imaging device; converting the medical image atthe mobile device to a standardized image file format compatible withthe destination based on the information on the destination for themedical image obtained from the metadata; encrypting the convertedmedical image file on the mobile device; and transmitting the encryptedmedical image file from the mobile device to a server for routing of themedical image file to the destination for the medical image file.